第16章 案例：软件产品与网站设计

前面的章节把界面讲透了，这一章换一种讲法：不按页面讲，按"一个人从起念头到收到钱"的顺序讲。这一章里有两个案例，代表软件行业里最常见的两种活法：

• 案例 A：一个人做一个 SaaS 小工具。自己做产品、自己找用户、自己收订阅费。前期几乎不赚钱，但做起来之后有复利——今天写的代码，明天还在替你挣钱。
• 案例 B：接私活做企业官网 / 小程序。客户给钱、你交付、结清走人。现金流快，但每一单都要重新投入人力，停下来就没有收入。

这两件事用的是同一个引擎，但用法差别很大：案例 A 重在"把需求想清楚、把设计定下来"，案例 B 重在"把工期压住、把验收做扎实"。读完这一章，你应该能判断自己现在更适合走哪条路，以及走的时候第一步点哪里。

你将学会

• 用五条自检标准判断一个软件想法值不值得做，以及怎么用「AI 问答」和「深度研究」在半天内验证它
• 「项目描述」「项目目标」的差版本与好版本分别长什么样，为什么写得差会导致后面全部返工
• 从需求对齐到创建任务的完整实战流程（含 8 轮对话范例、PRD 检查清单、MVP 范围划定方法）
• 第一周怎么跑通最小闭环、任务卡住怎么处理、第一个可访问版本的验收标准怎么写
• 接单型业务怎么用「现有项目导入」把客户资料变成项目、怎么用时间片权重压住关键路径工期
• 两类生意的横向对比：该盯什么指标、该建哪些 Agent、什么时候该从接单转做产品

一、两个案例，两种活法

先把两个案例的骨架摊开，你一眼就能看出它们的差别在哪。

还有一个共同点要先说明：不管哪一类，真正的瓶颈都不在"AI 会不会写代码"，而在你能不能把要做的东西讲清楚。前面第 10 章讲的是"入口在哪"，这一章讲的是"话怎么说"。同一个软件工程向导，需求对齐聊十分钟和聊四十分钟，后面返工次数可以差好几倍。

二、案例 A（一）想法阶段：先想清楚再动

案例 A 的设定是这样：你是一个会一点技术、也愿意学的一人公司 CEO，想做一个面向海外小电商的"退货政策自动生成器"——商家填几个问题，系统帮他生成一份合规的退货政策页面，按月收几美元。这类工具的特点是：目标用户明确、功能不复杂、不需要接支付以外的复杂系统。我们用它当例子走完全程。

你现在的状态是"想法有了，但不知道值不值得做"。这时候最容易犯的错是直接开项目让 AI 去写代码。写代码很快，写得不对才是浪费——因为错误的成本不在写，而在写完之后推倒重来。

1. 五条自检标准：先花二十分钟判断值不值得做

在打开任何页面之前，先把下面五个问题答一遍。答不上来就别急着建项目，答完了你能省下很多天。

五条里如果有两条以上答得含含糊糊，别急着建项目。这时候的正确动作是去问 AI、去查竞品，而不是去写代码。下面两小节就是干这个的。

2. 用「AI 问答」做一次可行性对话

项目里有一个「AI 问答」页面，它是你和 AI 的"项目内会议室"——比普通的 AI 对话多了两个能力：它能检索你的项目知识库，也能把回答里值得留下的内容提升为优秀案例，以后 AI 回答问题时会参考这些案例。

页面顶部有两个按钮：引导建项 和 项目导入；输入框下面有三个勾选项：知识库检索（use_rag）、案例 Few-Shot（use_few_shot）、联网搜索（use_web_search）。输入框的提示是 请输入你的问题，例如：如何搭建获客流程？（还没提问时，回答区显示引导语「输入问题，AI 将基于项目知识库与优秀案例进行引导式回答」），右边是 提问、停止、清空。

• 知识库检索：让 AI 先查你上传的资料再回答，减少瞎编。项目里还没资料时勾不勾都行。
• 案例 Few-Shot：让 AI 参考历史优秀案例的风格来回答。用得越久越有用。
• 联网搜索：让 AI 去网上查。做竞品和市场判断时要勾上，不然它只能凭记忆答，容易过时。

每条 AI 回答下面有三个按钮：采纳 拒绝 修改。这不是走过场——你点「采纳」的问答会被标记为可用经验，被采纳多了以后会提示 「已提升为优秀案例」，进入 Few-Shot 池反哺后面的回答。所以第一次做可行性判断时，认真点这几下，后面能省很多重复解释。

3. 用「深度研究」摸竞品：它能做什么、不能做什么

AI 问答适合"问人"，深度研究适合"查资料"。它做的事很具体：把你给的主题拆成一串子问题，逐个去网上搜索 + 检索你的企业知识库，最后汇总成一份带来源的结构化报告。页面上那句说明写得很清楚，我就不改写了。

页面标题「深度研究」，右上角两个按钮：发起研究 刷新。列表里每行显示「研究主题 / 状态 / 进度 / 子问题 / 来源 / 发起时间」，操作列是 详情、转 auto-ops 任务、取消。如果一条研究都没有，空态写着 「暂无研究任务，点击「发起研究」开始」；如果顶栏还没选公司，空态会提醒 「请先在顶部选择公司」。

点「发起研究」弹出对话框，字段如下：

底部的 开始研究 在主题为空时是灰的，这个设计是对的——空主题的研究没有任何意义。

报告出来后点 详情，右侧抽屉里是三个部分：研究报告（一个总览 + 每个子问题的结论，结论下面挂着来源标签，标签上会写「网络」或「知识库」以及相似度百分比）、子问题（拆出来的问题清单，还没拆完会显示「拆解中...」）、来源引用（每条来源带标题、摘要和原始链接）。

深度研究能做和不能做的，先分清楚

三、案例 A（二）立项目：字段怎么填才不返工

想法验证过了，下一步是把它变成系统里的一个项目。这一步看起来只是填几个框，但这里填错，后面每一步都要返工。

1. 先选对公司，再建项目

项目必须挂在公司下面。进「项目管理」之前先看顶栏的公司切换器选对了没有，否则项目列表顶部会提示 请先选择或创建一个公司，同时 新建项目 按钮是灰的。这个坑第 03 章讲过，这里只提醒一句：如果你打算同时接单和做产品，建议一开始就分成两家公司（比如"某某工作室"和"某某产品"），因为公司级知识库与账本是分开的，混在一起以后很难拆。

2. 项目类型：为什么选「软件开发」

下拉里一共五个选项：软件开发 / 电商运营 / 内容创作 / 智能制造 / 通用业务。案例 A 选「软件开发」。

有必要如实说明它的作用边界：当前版本，项目类型不会改变自动运营的执行逻辑——选「软件开发」并不会让 AI 自动去写代码。它的实际用途有三个：列表里的分类标签、内置岗位与任务模板的筛选口径，以及走「引导建项」时作为项目档案种子喂给 AI。

那为什么还要认真选？因为模板筛选这一条是实打实的收益：选「软件开发」时，系统给你的岗位模板和任务模板会更贴近软件项目（产品经理、全栈开发这类），而不是电商选品、内容排期那套。选错不会出错，只会让你在模板库和 Agent 组织里多绕几圈。

3. 项目描述：差版本 vs 好版本

多行文本框，提示 简要描述项目概况，最长 2048 字。这是整个向导里最重要的字段之一：走「引导建项」时，描述会和目标、类型、行业一起作为项目档案种子写入会话，AI 据此生成执行策略（里程碑、关键路径、目标拆解、需要的岗位）并拆出初始任务。

写法上只有一句话要记：写清三件事——做什么生意、卖给谁、现在手上有什么。下面两版对比，你一看就知道差别在哪。

4. 项目目标：差版本 vs 好版本

同样会喂给 AI。目标是告诉 AI「什么算成功、多久内」，它用来判断任务优先级，以及"这件事到底做完没有"。写目标要有可衡量的结果 + 时间。

5. 运行模式与预算：第一周的示例填法

运行模式单选三项：全自动 / 半自动 / 手动，默认停在「半自动」。这里提醒一次那个容易搞混的地方：创建时叫「手动」，进项目后到「自动运营控制台 → 调整运行模式」时叫「人工审核」，是同一个东西（内部值都是 manual）。

案例 A 的示例填法：

提交创建后，向导汇总页点 提交创建，会提示 「项目创建成功」。此时项目状态是草稿，还不能跑。从草稿到能派任务要三步：录入 / 开通服务器 → 点 确认部署完成 → 点 启动。这三步在第 03 章第七节，别跳过。

四、案例 A（三）用软件工程向导把想法变成可执行工程

现在到了这一章的核心。你的想法还在你脑子里，接下来要做的事只有一件：把它变成一份 AI 能照着执行、你也能照着验收的设计文档。做这件事的地方叫「软件工程向导」。

先说清楚为什么要绕这一圈，而不是直接说"给我做个退货政策生成器"。

保存后有件事会发生，值得单独说：系统不会立刻创建一条可执行任务，而是先建一条状态为规划中（planning）的任务，然后自动弹出七步向导。「规划中」是个不会被自动执行的状态——调度器会跳过它。这是故意设计的：在你把设计确认完之前，AI 绝不会自己跑去写代码。关掉弹窗或刷新页面，向导进度也会保留，任务列表里它的操作列会出现 继续规划，下次点它回来就从原来那一步接着做，不用从第 1 步重新聊。

顺手说一下新建任务弹窗里这一版新增的「软件名称」字段（可留空 = 系统自动命名）。它决定向导产出的文档落在哪个文件夹：{项目工作区}/{软件名称}/PRD.md、TAD.md、TAD/*.md、dev-plan.md。填一个看得懂的名字，同一项目里多个软件工程的文档就不会互相覆盖。

底部按钮会随步骤变化：上一步 下一步 保存并下一步 应用评审 创建任务。每个按钮的详细含义第 10 章已讲过，这里只讲案例 A 的实际用法。

1. 第 1 步 · 需求对齐：一次完整的 8 轮对话

输入框的提示是 描述你的软件工程需求（目标、功能、技术栈等）...，右边是 发送。下面是一份真实用法的对话范例——注意每一轮你都在回答 AI 的问题，而不是一口气把话说完。这才是"对齐"，一口气说完那叫"下单"。

点「下一步」时，系统会把这段对话自动总结成一份精简摘要（这一步在后台完成，即使总结失败也不会打断流程）。

2. 第 2 步 · 生成 PRD/TAD：界面上转圈是正常的

点完「下一步」，界面会显示 「AI 正在撰写 PRD 和 TAD，请稍候...」。这一步 AI 在写两份文档：

两份文档会以文件形式存在项目工作区里，文件名是 PRD.md 和 TAD.md（就放在你填的软件名称对应的文件夹下）。这一步是全程较慢的一步，转圈属正常，别重复点按钮——重复点可能触发多次生成，白花钱。万一生成失败，界面会进入失败态并给出「重试」按钮，不用傻等转圈，点重试即可。

3. 第 3 步 · PRD 确认：该检查什么

生成后切到文档预览页，左上角显示 PRD.md，右上角有 编辑 / 预览 切换——预览是排版好的样子，编辑是纯文本，你可以直接改。改完点 保存并下一步，你的修改会覆盖 AI 的版本。

案例 A 的 PRD 骨架清单，逐条对：

4. 第 4 步 · TAD 确认：不懂技术也能看懂的三件事

界面和第 3 步一样，文档名变成 TAD.md。你不需要看懂全部，看这三个点就够：

1. 有没有引入你要额外花钱或额外注册的东西

   文档里如果提到"需要接入某某第三方服务"，问自己愿不愿意为它付钱、愿不愿意注册账号。案例 A 的第一版最好零第三方依赖——除了模型本身。

2. 数据表里有没有你业务上必须记的东西

   案例 A 至少要能看到：账号、表单答案、生成的政策内容。如果表结构里连"表单答案"都没有，那它大概是打算重算一遍——这不是你想要的。

3. 模块名你看得懂吗

   因为第 6 步会按这里的模块拆分干活。如果模块名是你看不懂的缩写（比如"BL-Core-X"），说明它拆得不清楚，退回第 3/4 步把它改成人能看懂的名字，再往下走。

同样，改完点 保存并下一步。

5. 第 5 步 · 评审对话：把疑问一次问完

输入框提示 输入评审意见，与 AI 多轮讨论 PRD/TAD...。这是一个"提意见"的环节，把你在前两步没搞懂、不放心、想调整的地方直接说出来。聊完点 应用评审，AI 会按你这轮的意见重写 PRD 和 TAD。

要留意一个副作用：「应用评审」不是"确认"，而是"按我说的改一遍文档"，它会带着这一轮对话重新生成完整文档并覆盖原来的版本。所以如果你对现有文档很满意、只是随口说了两句，宁可先不点。覆盖也不是没有退路——系统在覆盖前会把旧版留一份（PRD.prev.md / TAD.prev.md），真改坏了还能找回上一版。

6. 第 6 步 · 生成模块：最慢的一步，别在这里放弃

点「应用评审」后进入这一步，界面显示 「正在生成模块文档与开发计划...」。所谓"模块"，就是把一个功能拆成一块块相对独立的部分。案例 A 可能被拆成：账号与登录、问题表单、政策生成引擎、结果展示与复制、合规规则库。系统会从你确认过的 TAD 里提取模块清单，为每个模块单独生成一份详细设计文档，最后再生成一份开发计划。

这一步可能全程最慢，因为每个模块都要调一次模型。如果你觉得拆得太细，正确做法是退回第 3/4 步把 TAD 里的模块划分改粗一点再重新生成，而不是硬等。和上一步一样，这一步失败也会给出失败态与「重试」按钮（不再停在转圈页），点「上一步」也能回到正确的前一屏。

7. 第 7 步 · 创建任务：这才是"排上班"

最后一步会出现绿色提示 「PRD / TAD / 模块文档已生成完毕」，下面是一个只读文本框，标题是「最终任务提示词（将用于创建任务）：」，里面就是要交给 AI 执行的完整指令。确认无误点 创建任务，提示 「软件工程任务已创建」，向导关闭，任务列表刷新。

8. MVP 范围：第一版只做这 5 个功能

这是整章最容易被忽略、也最容易失控的地方。软件类项目死在"功能太多"上的，比死在"做不出来"上的多得多。案例 A 的第一版范围建议这样划：

然后是同样重要的另一半：明确不做的 10 件事。把这张清单也写进 PRD 的"不做什么"里，AI 才不会"顺手"帮你加上。

1. 不做支付

   第一版收不了钱不要紧；支付会牵扯对账、退款、税务，至少占掉一周。

2. 不做历史记录 / 保存多份政策

   看起来简单，实际要做列表页、详情页、删除、配额，功能会翻一倍。

3. 不做嵌入脚本 / 生成可挂载的链接

   "先能复制文本"就够了。嵌入会引入跨域、样式冲突、安全一堆事。

4. 不做模板市场 / 多套模板选择

   一套够用。多模板会带来"选哪个"的决策成本和模板维护成本。

5. 不做多语言

   先只做英文。多语言是典型的"看起来很酷但没人因此付费"的功能。

6. 不做团队 / 多用户协作

   你的用户就是一个人，别提前做权限体系。

7. 不做数据看板 / 统计后台

   你自己想看的东西，用一个查询就够了，不用专门做页面。

8. 不做移动端适配

   这类工具的付费者基本在电脑上操作。移动端放在第二版。

9. 不做邮件通知 / 营销自动化

   等你有人要通知的时候再说。第一版连用户都还没有。

10. 不做管理员后台

    需要看数据时，直接查数据库或让 AI 给你生成一段查询。给自己做后台是最典型的浪费。

9. 向导走完之后：任务卡长什么样

向导创建的是一条任务，但案例 A 的第二周你还会陆续建别的任务。下面这份示例任务卡，可以帮你理解每个字段的实际作用。

几点说明：时间片权重（1–10）决定这个任务每轮能分到多少时间。默认 10 个时间片，权重越大占得越多。软件工程任务是重活，给 5；写文案这种轻活给 1。引擎上，凡是交付物是代码 / 网页 / 能运行的东西，一律用循环执行；写文案、做整理这类用 Agent 智能体就够了。如果你选了 Agent 引擎又选了软件类任务，界面会跳出一条告警原文：「Agent 引擎可能无法完成软件交付，仅适合简单项目，建议使用循环执行」——看到它就把引擎改回去。

五、案例 A（四）第一周：跑通最小闭环

向导走完、任务创建出来，接下来这一周你的目标只有一个：让一个"打开链接能点"的东西出现在世界上。不要在这一周加任何新功能，也不要改设计。

1. 第一周每天做什么（示例安排）

2. 遇到"任务一直不完成"怎么办

这是第一周最常见的问题。按这个顺序排查，别一上来就重启：

1. 先确认它是不是真的在跑

   去运行轮次页看有没有新的轮次记录（列里有「轮次 / 状态 / 模式 / 引擎 / 耗时（秒）/ 花费（元）/ 开始时间」）。如果很长时间没有新轮次，可能是自动运营被暂停了（预算熔断或兜底暂停），去控制台看状态标签。

2. 看任务状态，是不是卡在"规划中"

   如果状态还是规划中，说明向导其实没走完。回任务列表点 继续规划 把它走完。

3. 看日志尾部，判断它是"在做"还是"在绕"

   运行轮次页可以展开日志，标签有 assistant / user / system / thinking / tool_use / tool_result。如果它反复在同一个地方打转（比如反复读同一个文件、反复失败重试），那就是卡住了，需要你介入。

4. 看是不是被人工节点挡住了

   如果它做了"需要你点头"的动作，会创建一个人工处理节点。去人工处理节点页看有没有「待处理」的条目，有就点 确认完成。

5. 最后才考虑补充提示词或调整范围

   如果确认是"它理解错了"，不要直接暂停重来。当前界面上没有独立的「注入」按钮，正确做法是回任务列表点「编辑」，把补充说明写进弹窗里的「提示词模板」字段——比如"政策里必须包含免责声明，上一轮漏了"，它会作为任务级提示词在下一轮生效（优先级：任务级 > 角色级 > 项目默认）。注意任务描述创建后不可修改（它是独立验收的对照依据），补信息就走提示词模板这条道。这比推倒重来省得多。

3. 返工怎么处理

验收结论有三种：通过（pass）、返工（redo）、驳回（reject）。看到"返工"别慌，这是正常流程的一部分。正确的处理顺序是：

1. 先看验收报告说了什么

   在验收记录页点详情，能看到「执行者」和「验收 Agent」，以及评分和报告。报告会写清"哪一条没达到"。

2. 判断是哪一类问题

   分三种：（a）需求没说清——那就补一句说明，走软件修改或补进任务的提示词模板；（b）AI 做法不对但需求是对的——用软件修改把"应该怎样"讲清楚；（c）改坏了——优先用自动备份恢复到改动前，再重新提一个范围更小的需求。

3. 一次只提一个小改动

   不要一次把五条意见塞进去。做不精、验收难、出问题难定位。一条一条来。

4. 第一个可访问版本的验收标准怎么写

这是案例 A 里最值得抄下来的一段。因为界面上没有单独的验收标准输入框，你要把它写进任务描述或软件修改的需求里。一份好的验收标准长这样——每一条都能"打开页面点一下"来验证：

5. 上线：部署这件事你能在界面上做的部分

代码写完不等于跑起来。第 10 章讲过一句关键的：改动要真正生效，需要项目开启「自动构建部署」。路径是：

没开这个开关，AI 的改动可能停留在"代码写好了"但没上线。功能管理页里还有一项 「自动备份」，建议一起打开。顺手也可以点一下页面上的「AI 智能建议」里的 分析项目并建议，它会根据项目当前状态告诉你该开哪些高级功能，建议会带「高 / 中 / 低」优先级。

6. 服务器实例页签：你会用到的三个按钮

案例 A 第一周你大概率会打开这个页签。它上面有三类按钮，各管一件事：

另外，页签里那行 HMAC Secret（旁边有 显示 / 复制 / 重新生成 三个按钮）是平台和你的项目服务器"对暗号"用的密钥。它有一句很重的提醒：重新生成后旧密钥立即失效，必须同步到项目服务器配置，否则正在跑的项目会"失联"。第一周不要动它。项目列表卡片上有 连接测试，点一下如果出现绿字「连接成功：{ip}:{port}，HMAC 验证通过（{ms}ms）」，说明平台和你服务器之间的通道是通的。

六、案例 A（五）第二、三周：从能用到有人用

第一版跑通了，接下来这两周做两件事：把明显不好用的地方改掉，以及找到第一批愿意用的人。这两件事同时做，不要等"功能完美了再找人"——你等不到那一天。

1. 加功能 / 改功能的正确姿势

已经做好的东西要改，走的是软件修改，不是重新开一个软件工程。进入方式：

保存后弹出标题为「软件修改」的对话框：顶部显示「源软件工程 / 工程 ID」，中间是聊天区（输入框提示 描述你想如何修改这个软件工程...，右边 发送），下面是「任务提示词草稿」和 再生成一次，底部是 取消 和 确认创建任务。

它的精髓是两段式：先在聊天区把"改什么、改成什么样"聊清楚，AI 会把改法整理成一段任务提示词填进草稿框；你看草稿到位了，再点确认创建。草稿框里的内容你可以手动改（提示原文是「AI 回复将自动填入此处，可手动编辑后再确认创建」）。如果草稿是空的就点确认，会弹警告 「任务提示词草稿为空，请先与 AI 对话生成」，任务不会被创建——这是在保护你。

三个修改需求范例：坏写法 vs 好写法

2. 邀请种子用户：先找 10 个人，不找 1000 个

第一版能用了，接下来最重要的事不是加功能，而是找到愿意真实使用的 10 个人。示例路径：去北美独立站卖家聚集的社群，用"我做了个小工具，免费帮你生成一份退货政策，你用完告诉我哪里难用"这种话去邀请。关键是把"用"和"反馈"绑在一起——只要你愿意听完他的抱怨，多数人会给你十分钟。

注意本章的纪律：这里说的"发邀请、发邮件、发帖"都是对外动作。在半自动模式下，这类对外动作属于关键决策节点，需要你确认之后才继续；系统也可能为它创建一个人工处理节点（通道可能是红-强制 / 黄-敏感 / 绿-例行；自主级别 L0–L3）。这是底线，不是麻烦：AI 可以帮你把邀请文案写好，但"发出去"这个动作要你点头。

3. 把反馈变成任务：两条路

用户跟你抱怨了，接下来是"把抱怨变成 AI 能做的事"。有两条路，各有适用场景。

路一：直接建任务。如果反馈很小很明确（"复制按钮点了没提示"），直接在任务管理建一条软件修改任务，用上面那套"改什么 → 改成什么样 → 不能碰什么 → 怎么验证"的写法。这是最常见的情况。

路二：从会议导入里转。如果你和用户开了语音会、或者你手上有一份聊天记录，先把内容整理进去：

页面标题「会议内容导入梳理」，有两个标签页：上传文件（按钮 选择会议文件，支持 txt / md / docx / pdf / xlsx / pptx，暂不支持音视频）和粘贴文本（提示 粘贴会议记录文本，AI 将自动梳理摘要、决策与行动项）。工具条上可以先选「目标知识库（可选）」，梳理完自动入库 RAG。

梳理完成后，详情里会有四块：参会人 / 会议摘要 / 决策 / 行动项。行动项每一条右边有一个 转 auto-ops 任务 按钮，点了会先问你一句「将该行动项转为 auto-ops 任务？」——确认后它就变成一条任务进排队。如果没有行动项，会显示空态「无行动项」。

4. 给产品做一个公开的"使用文档智能问答"

这是案例 A 最划算的一个动作：用「客户页面」给产品做一个公开的问答页，把"用户常问的问题"变成自助服务。它对外只开放你指定的知识库，不需要对方登录，访问门槛极低。

页面标题「客户页面」，右上角 新建分享。列表里每行显示：名称 / 简介 / 知识库 / 状态（一个开关，可随时启停）/ 访问链接（显示成 /s/{token 前 4 位}****）/ 过期时间（没设就显示「永久有效」）；操作列是 编辑 日志 重置链接 删除。一条都没有时，空态是「暂无分享，点击右上角「新建分享」创建对外问答页」。

点「新建分享」弹窗，逐个字段这样填：

保存后弹出成功对话框，里面有一条必须看清楚的红字提醒：「请立即复制访问链接，token 仅本次展示，关闭后不可再查看」。下面写着「公开访问链接」，旁边是 复制链接，底部是 完成。

用户打开这个链接看到什么？一个标题为「AI 智能问答」的页面，输入框提示「请输入您的问题…」，最多能输入 2000 字（下方有实时字数提示）。他问、它答，就这么简单——不需要注册、不需要登录。要提醒用户一句：这段聊天记录只存在他自己的浏览器里，刷新页面就没了；服务端不留存公开问答的对话正文，你能回溯的是「访问日志」里的问题与状态。

你要盯的是访问日志：在列表里点 日志，右侧抽屉标题「访问日志」，每行显示「问题 / IP / 状态 / 输出 Token / 成本 / 时间」。状态有三种：正常（ok）/ 拦截（blocked）/ 过期（expired）。没有记录时空态是「暂无访问日志」。

七、案例 A（六）第一个月复盘与调整

1. 第一个月盯哪几个数

第一个月不要盯收入（大概率是 0），盯这四个：

这些数字在哪里看、怎么读，第 13 章讲得很细。这里只给你一个判断口径：返工率高，问题在需求（你这边）；任务完成率低，问题在任务拆分或引擎选择；预算消耗速率突然变快，先查是不是有任务在打转。

2. 三个典型问题的处置

3. 该不该加第二个 Agent

第一个月结束，你会面临一个选择：要不要从"一个人 + 一个全栈 Agent"扩成"产品 + 研发 + 客服"。判断依据只有一条：有没有一类活儿已经多到你必须亲自处理，而它又是重复的？

加 Agent 的入口是智能体中心：

那里还有岗位模板库（直接用现成岗位，省去从零配）和技能库（范围分「组织级」和「项目级」，项目级的技能可以点「提升为组织级」，让其它项目也复用）。如果你不想手动判断，可以打开组织进化页，点「重新评估」让系统按运营数据给出建议——建议类型有 role_add 增员 / scale_out 扩容 / skill_attach 技能装配 / stage_upgrade 阶段升级，每条都要你「确认 / 暂缓 / 拒绝」，也可以点一键扩编让它自动建角色、装技能、上岗测试、进调度。确认时的原文提示是「确认采纳建议「X」？系统将自动完成扩编/装配并上岗。」——扩编要花钱，所以默认要你确认，这不是多此一举。

八、案例 B（一）交付型业务：这类生意的特点

案例 B 的设定：你接了一个客户的活——一家做工业零配件的公司要做官网，外加一个能展示产品目录的小程序。预算示例几万元，工期示例三周，客户自己有个旧网站和一堆产品手册 PDF。

先看清楚这类生意的性质，它和案例 A 完全是两回事：

还有一个容易被忽略的差异：交付型业务的"对外动作"更多。给客户发方案、发报价、发上线通知、发验收单，全都是对外动作。在半自动模式下，这些都走关键节点确认；系统也可能为它们创建人工处理节点（通道 red 红-强制 / yellow 黄-敏感 / green 绿-例行；自主级别 L0–L3）。把它当成流程的一部分，而不是障碍——恰好，客户也很在意"每一条承诺都有人确认过"。

九、案例 B（二）接单阶段

1. 需求沟通清单：必须问客户的 20 个问题

接到一个活，第一件事不是报价，是把需求问清楚。下面这份清单按五组排列，建议直接存成模板，每次接单对一遍。问完这 20 个问题，你才可能报出一个不亏本的价。

2. 报价单结构

给客户的报价单不能只有一个总价。客户要的是"我知道我的钱花在哪"。推荐的六段结构：

完整的报价单结构模板在附录 C，请配合使用。这里只强调一句：报价单里的"不含什么"比"含什么"更重要。事后扯皮几乎都发生在"我以为包含在里面的"。这个报价单本身也可以先在 AI 问答里生成初稿（用第一小节的 20 个问题答案当输入），再由你逐条核价。

3. 用 AI 快速出方案与原型描述

接单阶段最花时间的其实是"出方案"和"讲清原型"。这两件事都可以先让 AI 出初稿，你再改。操作位置就在项目的「AI 问答」页，把客户资料勾上「知识库检索」，把"要参考历史好方案"勾上「案例 Few-Shot」。

十、案例 B（三）交付阶段：把客户需求变成项目

1. 建项目：先把客户的资料全导进去

接单型业务不要从零建项目再手动填，直接用「现有项目导入」——这个页面就是为"手上已经有一堆资料"的情况准备的。

页面标题「现有项目导入」，左边卡片叫「项目信息与资料」，字段如下：

操作顺序是：先点 创建导入会话（因为上传资料需要会话），再点 上传到会话。右边卡片「AI 整理的项目上下文」会把资料整理成四项：项目背景 / 当前阶段 / 关键联系人 / 未决事项。整理好点 整理并完成建项，最后点 下一步：确认执行策略。

接着进入「引导建项」页。它是一套四步流程：「引导会话」（可以填会话 ID，留空则自动创建，按钮 读取会话 生成策略，状态标签是「策略已确认 / 策略未确认」）→「项目信息与对话补充」→「项目摘要」→「项目执行策略」（按钮 重新生成 确认策略 完成建项）。内部阶段是 research 调研 / input 信息录入 / summarize 摘要整理 / strategy 策略生成 / import 导入 / done 已完成。

2. 走软件工程向导：和案例 A 一样的七步，但关注点不同

项目建好之后，做网站这件事本身走的是和案例 A 完全相同的入口：

七步也完全一样：需求对齐 → 生成 PRD/TAD → PRD 确认 → TAD 确认 → 评审对话 → 生成模块 → 完成。但因为约束不同，每一步的关注点要换一换：

3. 任务拆解与时间片权重：工期紧，关键路径给高权重

软件工程向导创建的是一条大任务。做交付型业务，你还需要围绕它建几条配套任务（写文案、整理产品数据、准备图片、给客户做演示稿等）。这时候时间片权重的设置就是排期工具。

先回忆一下机制：系统默认有 10 个时间片，任务按"时间片权重"（1–10）占用时间片，每一轮推进一个时间片，任务轮流获得处理时间。所以权重越大，这个任务越早被推进、每轮得到的处理越多。

案例 B 的示例配置：

十一、案例 B（四）验收与交付

1. 给客户看的验收清单模板

验收扯皮的根源，通常是"客户以为包含的"和"你以为交付了的"不一样。解决办法只有一个：开工前就把验收清单给客户过一遍，让他签字确认。下面这份可以直接用，把方括号里的内容换成客户的实际情况。

2. 用验收记录留痕：别用微信说"做好了"

系统里有验收记录页，它是你留痕的地方。每条记录包含验收 ID、任务、结论、评分、报告、人工状态、抽样、成本、时间、详情；点开详情能看到「执行者」和「验收 Agent」——这正是三权分立验收的体现：干活的、验收的、批准的不是同一个 AI。

结论有三种：通过（pass）/ 返工（redo）/ 驳回（reject）；人工状态有待审批（pending）/ 已批准（approved）/ 已拒绝（rejected）。交付型业务里你可以这样用：

如果某条改动需要客户点头才能继续，系统会创建人工处理节点。节点卡片上会显示「通道 / 自主级别 L{n} / SLA（秒）/ 处理人 / 描述」，按钮有 确认完成 通知催促 升级处理 移动审批。通道的含义是：red 红-强制（必须人工，AI 不得代行）、yellow 黄-敏感（需要确认）、green 绿-例行（通知即可）。自主级别 L0 全自主执行 / L1 通知不等待 / L2 一键确认 / L3 强制人工审核。客户相关的对外动作，适当配置成红色或黄色通道，是合理的做法。

3. 变更需求怎么处理：新增任务还是改原任务

客户说"能不能再加一个页面"。这时候你面前有两个选择，选错了要么亏工时，要么把原来的活搅乱。

变更单模板在附录 C。它的作用只有一个：把"额外做的事"变成客户书面确认过的事。哪怕是微信上一句"好的，这个加"，也建议整理成变更单发一遍让对方回个"确认"。

十二、案例 B（五）交付后：沉淀与复用

交付型业务能不能越做越轻松，全看你交付后有没有沉淀。同一套流程做第三遍的时候，如果还像做第一遍那样从零开始，那你做的是苦力不是生意。

1. 把这单的 SOP 存成模板

项目里有一个「项目模板」页面，它就是干这个的：

页面标题「项目模板」，工具条上有类型筛选和行业筛选，右侧三个按钮：刷新、从项目导出模板、沉淀项目为模板。列表里每行有 详情 和 应用；一条模板都没有时空态是「暂无项目模板」。

「从项目导出模板」会弹一个小对话框，三个字段：给模板起个名字、选择分类、模板用途说明。

下次接同类单子，直接在模板列表里点 应用，就能省掉"从零想结构"的那两天。

2. 三种复用方式，各管一层

十三、第三部分：两个案例的横向对比

什么时候该做产品，什么时候该接单

这两个不是信仰问题，是现金流问题。三条实用的判断：

1. 先看你的现金流能撑多久

   存款只够撑三个月，就别去做周期长的产品——你会因为焦虑而频繁改方向，最后两头空。反过来，如果你有一年的缓冲，接单的机会成本就很高（同样的时间本可以做出一个会持续收钱的东西）。

2. 再看你手上有没有"别人愿意付钱"的证据

   接单赚到钱这件事本身就是证据：有人愿意为你的交付付费。做产品需要另一种证据：同一类痛被反复提到。如果在你接单的过程中，三个以上客户都在抱怨同一件事，那件事就值得做成产品——而且你的早期客户已经现成了。

3. 最稳的走法是"接单养产品"

   用接单的收入覆盖生活，用剩下的时间做产品。案例 A 和案例 B 完全可以放在同一个公司下的两个项目里各自推进（注意：两个项目不要混用同一个工作区）。等产品开始有稳定订阅收入，再逐步减少接单比例。这个过程典型是以季度为单位，不是以周为单位。

十四、本章小结与下一步

• 软件类项目分两种活法：做产品看需求与范围，接单看工期与验收。同一个引擎，两种用法。
• 想法阶段用五条自检标准筛一遍；用「AI 问答」做可行性对话、用「深度研究」摸竞品，但它不替你拍板。
• 「项目描述」写清做什么生意 / 卖给谁 / 手上有什么；「项目目标」给一个可衡量的结果加时间。这两个字段才真正影响 AI。
• 做新功能走「新建软件工程」七步向导，改已有功能走「软件修改」；绝不要直接建一个"开发 XX"的通用任务。
• MVP 范围靠"不做清单"收住；验收标准写成"打开页面点一下就能验证"的条目。
• 接单的三个关键动作：用「现有项目导入」导入客户资料、用时间片权重压关键路径、用验收记录与变更单留痕。
• 交付后花半天沉淀：模板（项目结构）+ 技能（怎么干）+ 知识库（知道什么）。

到这里，你已经走完了一个软件产品从想法到有人用的全过程，也看到了接单型业务的完整打法。但软件只是"能被文字和代码验收"的生意中的一类——内容、咨询、制造、本地服务这些行业，玩法和关注点又各不相同。下一章我们把四个行业的精简案例放在一起，让你快速找到和自己最像的那一个。

附录 A · 软件项目全流程时间线（Day 0 → Day 45）

这张表把案例 A 与案例 B 共用的动作串成一条时间线。"Day"是天数，不是日期——你不必严格按天推进，但顺序别打乱。最后一列"完成标志"是你能自己核对的东西：没达到就先别往下走。

附录 B · 需求与任务模板全集

下面 15 段都可以直接复制、替换方括号里的内容使用。软件类项目最容易出问题的地方不是"AI 干不好"，而是你给它的话太模糊——这些模板的作用就是把模糊的话变清楚。

B-1 项目描述范例

B-2 需求对齐开场（向导第 1 步）

B-3 PRD 检查清单

B-4 任务描述范例（5 个）

B-5 "加功能"修改需求（3 个）

B-6 验收标准（2 份）

B-7 客户沟通问题清单（接单前必问）

附录 C · 交付型业务报价与排期模板

C-1 报价单结构

C-2 三周排期表结构

C-3 变更单模板

附录 D · 两类生意的指标对照表

同一套引擎，两类生意该盯的数字完全不同。看错指标比不看指标更糟——它会把你引到错误的方向上。

附录 E · 这么做会翻车：软件类项目 10 个反模式

下面 10 条都来自软件类项目最常见的失败方式。每一条都写成"你会看到什么现象 / 后果是什么 / 正确做法是什么"，方便你对照自查。